Avant-propos

A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.

The World of Mathematics (1956)
— Bertrand Russell

» A qui est destiné ce document?

Les étudiants qui découvrent le langage, mes collègues enseignants qui cherchent un document de cours et d’exercice accessible, et … moi-même (pour organiser mes notes diverses)!

» A qui n’est-il pas destiné?

Si vous appartenez à l’une de ces catégories, ce livre n’est pas pour vous :

  • vous cherchez un livre de référence (pour cela, même s’il est en anglais, je conseille [FMS])
  • vous voulez vous perfectionner (ce livre n’est qu’une introduction)
  • vous souhaitez préparer la certification de l’OMG (mieux vaut vous plonger dans la spécification [SysML])

» Historique

Ce document est la compilation de plusieurs années d’enseignement de SysML depuis 2007, que ce soit :

  • au Master TI, de l’Université de Pau et des Pays de l’Adour (cours d’introduction avec mon collègue et ami Nicolas Belloir),
  • au Master Recherche SAID, de l’UPS (introduction),
  • au Master ICE de l’Université de Toulouse II - Le Mirail (introduction avec mon collègue et ami Pierre de Saqui Sannes),
  • au Master of Science de Göteborg, Suède (introduction réalisée par Nicolas Belloir),
  • à l’Universitad Autonoma de Guadalajara, au Mexique (40h de formation professionnelle aux employés de Continental),
  • ou plus récemment au Master GLRE (parcours "logiciels embarqués") de l’UPS.

Vous trouverez en référence (cf. Bibiliographie) les ouvrages et autres documents utilisés.

» Sur l’auteur

» Comment lire ce document?

»» Version électronique

Ce document a été réalisé de manière à être lu de préférence dans sa version électronique (au format PDF), ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.

Important Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, et c’est votre punition pour avoir utilisé du papier au lieu du support électronique!

»» Conventions typographiques

J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’AsciiDoc :

  • Des mises en formes particulières concernent les noms de personnalités (e.g., Jean-Michel Inglebert), etc.
  • Les références bibliographiques présentées en fin de document (cf. Bibliographie) sont complétées par le numéro des pages (lien clickable dans la version électronique de ce document) qui renvoie à l’endroit du document où elles sont citées.
  • Tous les flottants (figures, tableaux, définitions, etc.) sont listés à la suite de la table des matière.
  • Les termes anglais (souvent incontournables) sont repérés en italique, non pas pour indiquer qu’il s’agit d’un mot anglais, mais pour indiquer au lecteur que nous employons volontairement ces termes (e.g., Requirements).

» Pourquoi parler de "document"?

Parce que j’ignore la version que vous êtes en train de lire. A partir de l’original, plusieurs versions ont été générées grâce à AsciiDoc:

  • pour le web (Moodle) au format html
  • pour présentation en amphi au format slidy ou deck.js
  • pour impression au format pdf
  • pour lire au format Kindle (bientôt!)

» Utilisation et autres mentions légales

Dernière MAJ : 06/11/2012 - 23:18:17 CET
Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham. La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert. Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

N’hésitez pas à m’envoyer vos remarques en tout genre en m'écrivant ici.

Méthode pour cet ouvrage

Everything should be made as simple as possible, but not simpler.

— Albert Einstein

Mon approche pédagogique repose sur plusieurs principes bien établis :

La répétition

Par exemple certains diagrammes sont abordés plusieurs fois (comme le diagramme paramétrique). Le lecteur pourra avoir une impression de redite par moment. Sauf erreur de ma part (toujours possible!), c’est volontaire. En général les répétitions vont en niveau de précision, de détails et de complexité croissant.

L’illustration

Dans la mesure du possible, j’essaye de donner des exemples aux principes énoncés.

Le référencement

Les définitions ou autres affirmations sont tirées d’ouvrages de référence généralement citées.

La "carte de base"

J’aime réaliser une "carte" [1] qui sert à "placer" les différents concepts abordés. Il me semble que cela permet aux étudiants de raccrocher les nouveaux concepts aux précédents.

A part le chapitre d’UML à SysML, aucune connaissance particulière d’UML n’est nécessaire. Il s’agit d’un partie pris prenant en compte plusieurs points :

  • La plupart des ingénieurs systèmes ne connaissent pas UML
  • Les étudiants de STI2D ne connaissent pas UML et sont pourtant formés à SysML
  • Ceux qui connaissent UML auront sûrement plaisir à retrouver les bases

C’est quoi SysML?

Si vous ne deviez lire qu’un seul chapitre, voilà ce qu’il faudrait retenir…

Note
Carte d’identité
  • Date de naissance : 2001!
  • Version actuelle : 1.3 (2/6/2012)
  • Paternité : OMG/UML + INCOSE
  • Auteurs principaux
    • Conrad Bock
    • Cris Kobryn
    • Sanford Friedenthal

SysML , c’est :

  • Un ensemble de 9 types de diagrammes :
    • Diagrammes structuraux
      • Diagrammes de définition de blocks (bdd)
      • Diagrammes internes de blocks (ibd)
      • Diagrammes paramétriques (par)
      • Diagrammes de packages (pkg)
    • Diagrammes comportementaux
      • Diagrammes de séquence (seq)
      • Diagrammes d’activité (act)
      • Diagrammes de cas d’utilisation (uc)
      • Diagrammes d'états (st)

SysML , c’est (suite):

  • Un ensemble de types de diagrammes :
    • Diagramme d’exigence (req)
  • Un profil UML , c’est à dire une extension de cette notation
  • Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes

SysML , ce n’est pas :

  • Une méthode ou une démarche de développement de système
  • Un outil
  • Un raton laveur (c’est juste pour voir ceux qui suivent)

A propos du Bac STI2D

Si vous utilisez cet ouvrage dans le cadre du bac STI2D qui a introduit depuis 2011 la notation SysML au programme, nous donnerons ici (bientôt) des conseils sur l’utilisation de ce cours [2].

L’objectif en STI2D n’est pas de former des spécialistes de SysML mais de permettre à tous d’apprendre une notation pour la modélisation de système qui se veut universelle. Il ne faut donc pas viser la complétude ou même demander trop de détails. La logique de la démarche de modélisation et l’importance de la communication devront primer.

Un exemple fil rouge

L’exemple de système qui sera modélisé tout au long de ce livre en guise d’exemple est l’exemple d’un système de gestion et de supervision de crise. Les détails sont donnés en annexe (cf. Annexes).

Il existe un certain nombre d’autres exemple complets :

Introduction

La matrice qui nous servira de "carte de base" pour placer les activités ou les modèles, sera celle-ci :

Table 1. La carte de base
Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

» Points de vue

Dans un axe horizontal, j’ai différencié quatre grands points de vue :

Requirements

Les exigences et leur prises en compte sont un éléments critique pour le succès du développement du système. Sans explorer l’ensemble des activités d’ingénierie système (ce qui nécessiterait tout un volume du type de [reqs]) nous insisterons beaucoup sur cet aspect qui est souvent à l’origine de l’intérêt de SysML .

Structure

La description de l’architecture et des éléments constitutifs du système, avec les blocs, leurs relations, organisations internes, etc. constituera un point de vue important. C’est souvent la partie de SysML qui pose le moins de problème aux débutants.

Comportement

Le comportement d’un système est du point de vue de l’utilisateur final beaucoup plus important que la structure elle-même. C’est la partie qu’il est la plus à même d’exprimer, de comprendre (vos modèles) et de valider.

Transverse

Un certains nombre de concepts sont transverses aux trois points de vue précédents. Il s’agira principalement de parler de cohérence entre les phases de développement ou entre les points de vue.

» Phase de développement

Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :

Organisation

Une étape indépendante du type de cycle de développement envisagé (en V, agile, etc.) mais qui concerne la mise en place d’un cadre de travail qui permette un développement de qualité (outils, éditeurs, gestionnaire de version, de tâches, etc.)

Analyse

Cette phase vise plutôt à examiner le domaine du problème. Elle se focalise sur les cahiers des charges et les exigences. L’analyse débouche sur un dossier d’analyse qui décrit les grandes lignes (cas d’utilisation, architecture principale) du système.

Conception

Cette phase vise plutôt à examiner le domaine de la solution. Elle débouche sur un dossier de conception qui décrit les détails conceptuels de la solution envisagée (structure détaillée, comportement, etc.)

Implémentation

Cette phase traite des développements finaux (construction ou approvisionnement en matériel, développement de codes, etc.).

Différence avec l’ingénierie logicielle

Enseignant en informatique, je me retrouve souvent à enseigner SysML à des informaticiens. D’où ce petit exposé sur mon opinion de la différence entre les deux "mondes".

» Une ingénierie plus ancienne

Que ce soit généralement en terme de cycle de développement ou historiquement, l’Ingénierie Système arrive avant l’Ingénierie Logicielle. Les ingénieurs systèmes ont donc une longue expérience et des pratiques bien ancrées.

» Des systèmes plus complexes

On parle de système complexe lorsque l’on a affaire à :

  • un ensemble d'éléments humains et matériels en relation avec :
    • de nombreux éléments technologiques (Informatique, Hydraulique, Electronique, …)
    • intégrés pour fournir des services (finalité du système) en fonction de leur environnement
    • interagissant entre eux et avec leur environnement

Système complexe

On parle aussi de Système de systèmes quand un système :

  • doit gérer les interactions entre ses parties (ou composantes)
  • assure un comportement prévu à l’avance
  • gère les comportements (de l’environnement) inatendus

Système de systèmes

» Différents types d’analyse

Toute la question que l’Ingénierie Système cherche à résoudre est : comment passer des exigences au système de la façon la plus efficace possible.

Des reqs au système

Pour cela l’Ingénierie Système est découpée en plusieurs analyses, chacune avec un but bien particulier :

Analyse Fonctionnelle et/ou Comportementale

Des reqs au système

Analyse Structurelle

Des reqs au système

Analyse de performance

Des reqs au système

Analyses spécifiques

Des reqs au système

Pour arriver à combler le gap entre le système à développer et ses spécifications.

Des reqs au système

Normes et standards

Il existe un grand nombre de standards en Ingénierie Système . Cette section fera (bientôt) une revue de ces différents standards et organismes et de leur utilisation (IEEE, EIA, ISO, certification, NASA, INCOSE, AFIS, …).

Enfin, citons un rapport de 2010, le Rapport Potier, qui présente l'état des logiciels embarqués et qui sera utiles à ceux qui s’intéressent aux verrous technologiques liés à ce domaine.

L’Ingénierie Système génère beaucoup de documentation. Les processus de certification (par exemple dans l’aéronautique) sont encore basés sur des documents textuels.

Des documents aux modèles

Vue la complexité grandissante des systèmes, petit à petit cette ingénierie tente de passer d’une ingénierie centrée documents à une ingénierie centrée modèles. D’où l’importance de se poser la question des notations et langages pour réaliser et communiquer avec ces modèles (cf. [Notation]).

Les exigences

L’ingénierie des exigences est d’une importance capitale en Ingénierie Système . Nous renvoyons pour l’instant le lecteur au cours de Master qui précède ce cours.

Joke
Illustration: Humour (taken from here)

L’architecture du système

Liens avec AADL, …

Le comportement du système

Liens avec la V&V

Méthodes et démarches

SysML n’est pas une méthode. En effet aucune démarche n’est imposée pour l’utilisation des diagrammes, l’ordre logique dans lesquels il vaut mieux les réaliser, etc. La spécification ne porte que sur la notation elle-même. D’où le pluriel dans le titre de cette section : il existe presque autant de méthodes que d’entreprise développant des systèmes. Nous nous contenterons de donner ici quelques heuristiques (cf. Annexe Considérations méthodologiques pour la présentation de quelques méthodes bien identifiées) :

Heuristique : Approche itérative

Un diagramme ne doit pas être considéré comme définitif. Il peut être complété alors que l’on traite un autre aspect de la modélisation (exemple classique : ajout d’un nouveau block lors de la réalisation d’un diagramme de séquence). Quelque soit la démarche adoptée elle doit être itérative et permettre de revenir sur les premières étapes.

Heuristique : Niveau d’abstraction

Bien intégrer les niveaux d’abstraction dans votre démarche. SysML possède certaines constructions pour formaliser cet aspect (Packages par exemple). Nous matérialisons cet aspect par la partie verticale de la matrice (cf. [Matrice]).

Heuristique : Bien intégrer les niveaux d’abstraction dans votre démarche. SysML possède certaines constructions pour formaliser cet aspect (Packages par exemple). Nous matérialisons cet aspect par la partie verticale de la matrice (cf. [Matrice]).
Heuristique : Tous les diagrammes ne sont pas utiles

N’essayez pas de réaliser tous les diagrammes possibles pour votre système. Réalisez uniquement ceux qui sont utiles à votre cas particulier.

Pourquoi une nouvelle notation

Il existe une notation qui se veut "unifiée" pour les modèles : UML . Néanmoins cette notation est peu adaptée pour l’Ingénierie Système :

  • UML 1.x était complètement inadaptée :
    • Principalement pour les systèmes d’information
    • Peu de liens entre les diagrammes
    • Peu de liens entre les modèles et les exigences
  • UML 2.x n’est pas beaucoup mieux si n’est :
    • Implication des ingénieurs systèmes pour sa définition
    • Introduction du diagramme de structure composite

En conclusion UML est une bonne base :

  • Standard De facto en génie logiciel
  • Fournit beaucoup de concepts utiles pour décrire des systèmes (même complexes)
  • Stable et extensible (grâce notamment au mécanisme de profile)
  • Beaucoup d’outils disponibles

Mais…

  • Manque de certains concepts clés d’Ingénierie Système
  • Vocabulaire beaucoup trop « software » pour être utilisé par les ingénieurs systèmes (concept de classe ou d'héritage par exemple)
  • Trop de diagrammes (13 sortes)

Introduction à SysML

» Fiche d’identité

  • Date de naissance : 2001!
  • Version actuelle : 1.3 (2/6/2012)
  • Paternité : OMG/UML + INCOSE
  • Auteurs principaux
    • Conrad Bock
    • Cris Kobryn
    • Sanford Friedenthal
Note
Versions de la spécification de SysML

La version 1.0 du langage de modélisation SysML a été adoptée officiellement par l’OMG le 19 septembre 2007. Depuis, trois révisions ont été réalisées : 1.1 en décembre 2008, 1.2 en juin 2010, et 1.3 en juin 2012.

» Différence avec UML

Liens entre UML et SysML

images/diff.png

» Qui est "derrière"?

Industrie

American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …

Vendeurs d’outils

Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …

Autres organisations

AP-233, INCOSE, Georgia Institute of Technology, AFIS, …

» Organisation des différents diagrammes

Les 9 diagrammes SysML et leur lien avec UML

images/Figure4.1.png

Version abrégée des diagrammes

images/Figure4.1-bis.png

» Différence entre modèle et dessin

SysML n’est pas une palette de dessins et d'éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en SysML . Elle est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus. C’est pourquoi nous vous recommandons de ne jamais "dessiner" des diagrammes SysML [3], mais d’utiliser des outils dédiés (cf. section [Outils]).

Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :

Table 2. Organisation
Requirements, cf. [reqs] Structure, cf. [archi] Comportement, cf. [behavior] Transverse, cf. [transvers]

Organisation, cf. [orga]

pkg

pkg, bdd

pkg

Analyse, Conception, Implémentation [4]

req

bdd, ibd, seq, par

uc, seq, st, act

par

Outils SysML

Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :

Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.

Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d'éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.

Important Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation.

Principes de base

Abordons quelques principes généraux de SysML .

  • Chaque diagramme SysML représente un élément de modélisation
  • Chaque diagramme SysML doit être incluse dans un cadre (Diagram Frame)
  • L’entête du cadre, appelé cartouche, indique les informations sur le diagramme:
    • le type de diagramme (req, act, bdd, ibd, sd, etc.)
    • le type d'élément (package, block, activity, etc.)
    • le nom de l'élément
    • le nom du diagramme ou de la vue

Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type bdd) qui représente un package, nommé "Context".

Exemple de diagramme SysML

images/pacemaker-context.png

Organisation

Table 3. Organisation
Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

» Fondements

On abordera :

  • Le Package Diagram
  • Les différent types de packages
  • Les organisations possibles
  • La notion de Namespaces
  • Les Dependencies

» Le Package Diagram

  • Identique à UML , et classique pour les développeurs (java notamment)
  • Permet d’organiser les modèles en créant un espace de nommage (name space)
Note
Espace de nommage

Dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité.

Les modèles peuvent être organisés selon toutes sortes de considération (cf. [organisation]). Le mécanisme qui permet de les organiser est le package (paquetage).

  • hiérarchie "système" (e.g., entreprise, système, composant)
  • types de diagrammes (e.g., besoins, structure, comportements)
  • par points de vue
  • etc.

» Les différent types de packages

Il existe plusieurs types de package :

models

un package "top-level" dans une hiérarchie de package

packages

le type le plus classique : un ensemble d'éléments de modèles

model librairies

un package prévu pour être réutilisé (importé) par d’autres éléments

views

un package spécial pour représenter les points de vue

» Les organisations possibles

Les modèles peuvent être organisés selon toutes sortes de considération :

  • par hiérarchie "système" (e.g., entreprise, système, composant, …)
  • par types de diagrammes (e.g., besoins, structure, comportements, …)
  • par cycle de vie (e.g., analyse, conception, …)
  • par équipes (e.g., architectes, [IPT], …)
  • par points de vue (e.g., sécurité, performance, …)
  • etc.
Exemple d’organisation

images/pkg-organisation2.png

Exemple d’organisation

images/pkg-organisation-modelview.png

Exemple d’organisation

images/pkg-organisation.png

Exemple d’organisation

images/pkg-topcased.png

» La notion de Namespaces

Un package est un espace de nommage pour tous les éléments qu’il contient.

Note

Dans les outils SysML , vous pouvez demander à voir les noms complets (Qualified names) des éléments, c’est à dire le nom de l'élément prefixé par son (ou ses) package(s) (e.g., Structure::Products::Clock).

» Les dépendances

Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :

Dependency

une dépendance "générale", non précisée,
représentée par une simple flèche pointillée ----->

Use

l'élément "utilise" celui à l’autre bout de la flèche (un type par exemple),
représentée par le stéréotype ≪ use ≫

Refine

l'élément est un raffinage (plus détaillé) de celui à l’autre bout de la flèche,
représentée par le stéréotype ≪ refine ≫

Realization

l'élément est une "réalisation" (implémentation) de celui à l’autre bout de la flèche,
représentée par le stéréotype ≪ realize ≫

Allocation

l'élément (e.g., une activité ou un requirement) est "alloué" sur celui à l’autre bout de la flèche (un block la plupart du temps),
représentée par le stéréotype ≪ allocate ≫

» En résumé

SysML propose un certain nombre de mécanismes pour organiser les différents modèles, tirés pour la plupart d’UML .

» Questions de révision

  1. Quels sont les 5 types de dépendances entre packageable elements ?
  2. A quoi sert-il de renseigner les dépendances (donnez des exemples concrets) ?

Les exigences

Table 4. Place des Exigences
Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

» Fondements

On abordera :

  • L’organization des Requirements
  • Les Requirements properties
  • Les Requirements links
  • Les Requirements Diagrams
  • Les considerations sur la Traceability

» En résumé

Table 5. Déclinaison des Exigences
Requirements Structure Comportement Transverse

Organisation

⊕–, <<deriveRqt>>

Analyse

<<satisfy>> entre reqs et UC

Conception

<<allocate>>

Implémentation

<<satisfy>>, <<verify>>

» Questions de révision

  • Quelles sont les différences entre besoins et exigences ?

L’architecture du système

Table 6. PLace des aspects structurels
Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

» Fondements

On abordera :

  • l’organisation du système et des modèles
  • les Block Definition Diagrams
  • les Internal Block Diagrams
  • les Parametric Diagrams (pour les contraintes physiques)
  • les Sequence Diagrams (diagramme de séquence système)

» En résumé

En résumé…

» Questions de révision

Pour réviser…

Le comportement du système

Table 7. Place du Comportement
Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

» Fondements

On abordera :

  • les Use Case Diagrams (scénarios)
  • les Sequence Diagrams
  • les State Machines
  • les Activity Diagrams

» En résumé

En résumé…

» Questions de révision

Pour réviser…

Les aspects transversaux

Table 8. Aspects transversaux
Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

» Fondements

On abordera ici les aspects transversaux comme :

  • la traçabilité des exigences
  • les mécanismes d’allocation
  • le diagramme paramétrique

» En résumé

En résumé…

» Questions de révision

Pour réviser…

Une démarche parmi d’autres

Nous allons aborder le développement complet de notre exemple fil rouge en suivant une démarche classique et simple (utilisée par exemple dans [SeeBook2012], où proche de la démarche globale enseignée dans nos cous de DUT Informatique, ou encore proche des documents de référence en la matière [HAS2012], [KAP2007],[FIO2012]) :

  1. Spécification du système
  2. Conception du système
  3. Traçabilité et Allocations
  4. Modèle de test

Nous partirons du modèle des exigences produit initialement. Mais avant tout, parlons outils.

» Environnement de développement

Nous sommes des défenseurs des principes [DRY] et [TDD]. Nous allons donc réaliser nos diagrammes dans un outil et non "à la main" (de simples dessins). Nous choisissons ici l’outil TOPCASED pour des raisons que nous expliquerons ailleurs. La version utilisée pour réaliser les exemples de cette section est la version 5.2.

Un outil SysML seul ne suffit pas (cf. Outillage). Il faut penser à la documentation (cf. Génération de doc).

Outillage autour de SysML

Outillage autour de SysML

»» Outils

Il existe de nombreux outils SysML . Nous renvoyons le lecteur sur le site de SysML-France pour des informations sur les dernières versions des outils.

»» Génération de documentation

La plupart des outils permettent de générer de la documentation. Pour les outils basés eclipse comme TOPCASED, il est possible d’utiliser le plug-in GenDoc2.

Génération de documentation à partir de TOPCASED

GENDOC GENDOC

Les outils commerciaux comme Rhapsody permettent de générer de nombreux formats.

Génération de documentation à partir de Rhapsody

Rhapsody

»» Animation de modèles et simulation

Fortement liée aux outils, la possibilité d’animer les modèles ou encore d’effectuer des simulations est une exigence de plus en plus forte des ingénieurs systèmes.

Il existe de nombreuses possibilités. Citons par exemple :

Génération de code VHDL

L’outil RTaW propose, via génération de code VHDL de simuler les modèles. Voir une démonstration ici.

Simulation en Rhapsody

L’outil Rhapsody possède une interface très pratique pour faire du prototypage rapide.

Animation

Voir mon tutoriel (en anglais) disponible ici.

Animation de modèles en Artisan

L’outil Artisan permet également de faire de l’animation de modèles. Animation

» Spécification du système

Il s’agit ici de décrire le contexte et d’identifier les principaux cas d’utilisation du système.

» Conception du système

Chaque cas d’utilisation sera précisé (seq et act). Les données métier seront alors identifiées pour construire le modèle d’architecture logique (bdd et ibd) complété par la description des comportements complexes (st). Enfin le modèle d’architecture physique permettra de déterminer les aspects déploiement et constructions physiques d'équipements/

» Traçabilité et Allocations

Afin de consolider les différents modèles, les liens de traçabilité qui n’auront pas été déjà décrit [5] seront rajoutés en insistant sur les liens :

  • de satisfaction des exigences par les éléments de l’architecture,
  • d’allocation des éléments du modèle fonctionnel vers les éléments logiques,
  • d’allocation des éléments logiques vers les éléments de l’architecture physique.

» Modèle de test

Nous insistons dans l’ensemble de nos formations sur les approches test-driven, alors nous montrons dans cette section comment participer à la qualité du développement d’un système en formalisant (par exemple avec des diagrammes de séquence de scénarios à éviter) les test et les jeux de test.

Recettes et bonnes pratiques

La plupart des ouvrages sur un langage enseignent les éléments de ce langage, comme nous l’avons fait à la partie précédente. Nous allons ici partir du principe inverse : comment modéliser tel ou tel partie ou vue de mon système avec SysML. Un peu à la manière des ouvrages du type Cookbook, nous allons donner une liste non exhaustives de recettes. Les choix des éléments de modélisation sont arbitraires ou tirés de discussions (comme ce sera mentionné si c’est le cas).

» Architecture

Recette : Je souhaite modéliser mon système dans son environnement

C’est conseillé. Un block System permet de raccrocher tous les éléments qui le composent à un même niveau.

Dans l’exemple ci-dessous le système (le bloc Pacemaker) est lui-même un simple composant d’un élément de plus haut niveau : le contexte du système (le bloc Context) qui relie alors le système à son environnement.

Le contexte du Pacemaker ([SeeBook2012])

Le contexte du Pacemaker

Voir aussi la section [contexte].

» Comportement

Recette : Je souhaite modéliser les différents modes (nominal, alternatifs)

Un diagramme d'état peu modéliser les différents modes et les événements qui produisent les changements de mode.

» Patrons de conception système

Mérite une section ??

Considérations méthodologiques

Exemples de démarche autour de SysML , lien avec la section Méthodes.

Exercices de révision

Reprendre ici les questions des chapitres (à organiser en fichiers!).

» Quizz

»» Sujet

Un quizz en ligne est disponible ici (me contacter pour le mot de passe).

En voici une capture d'écran :

Crosword

»» Corrigé

L’ensemble des questions du quizz a été généré à partir de ce fichier quizz (qui contient les réponses).

» Mots croisés

»» Sujet

Voici un petit exercice (en anglais pour l’instant, désolé) pour changer :

Crosword
Vertical (across)
  • 2. outside-inside connection
  • 4. the full name of a model element is also a … name
  • 6. the black diamond in SysML
  • 9. History is one of them
  • 10. what a block can do
  • 13. between states
  • 14. a supporter of SysML
Horizontal (down)
  • 1. used to describe a flow of actions
  • 3. message represented by a regular (unfilled) arrow
  • 5. each use case is advised to be linked to at least one of them
  • 7. they are handled in SysML by Packages
  • 8. communication entity in a seq
  • 11. a supporter of SysML
  • 12. number of diagrams in SysML

»» Corrigé

             A
DELEGATION   C
     S       T
     Y   QUALIFIED
     N       V
   R COMPOSITION
 M E H       T A
 E Q R       Y M
PSEUDOSTATES   E
 S I N         S
 A R OPERATION P
 G E U      M  A
 E M S   N  G  C
   E     I     E
TRANSITION INCOSE
   T     E

Liens utiles

Historique de SysML

Un point sur les évolutions de SysML .

D’UML à SysML

Un point sur comment aborder SysML quand on vient d’UML .

Idées de projets

Quelques exemples de sujet propice au développement SysML.

Challenges et questions ouvertes autour de SysML

FAQ

Cette Frequently Asked Question a été construite par expérience, en regroupant les questions des étudiants durant mes différentes interventions. J’ai aussi ajouté des questions souvent rencontrées dans les journées organisés par SysML-France.

Note Voir aussi cette FAQ très bien faite.

Cette FAQ peut servir de base à la révision d’examens (cf. aussi [Exos]).

» What is the current version of SysML and how can I obtain it?

Verson 1.3 and here is the specification link: http://www.omg.org/cgi-bin/doc?formal/10-06-02.

» What changes were made during the last revision?

Notable changes in Version 1.2 of SysML include:

  • Synchronization with changes in UML 2.3
  • Conjugate ports metamodel and notation
  • Naming of interruptible activity regions
  • Inclusion of UML instance specifications -Inclusion of UML structured activity nodes
  • Inclusion of UML multiple item flow notation
  • Improvements to Unit and QuantityKind support for value types, and a non-normative model to define systems of units and quantities
Note The SysML v1.3 Revision Task Force led by Roger Burkhart and Rick Steiner is continuing to work on proposed improvements to SysML based on feedback from the systems modeling community.

» How do we setup ranges (limits) of (input) variables (in a par for example)?

In the details or the definition of the Flow Item.

» What does the {strict} keyword means for profile application?

No other meta-elements than the one in the applied profile were used (e.g., you can use a tool supporting the profile with confidence).

The semantics of UML profiles ensure that when a user model “strictly” applies the SysML profile, only the UML metaclasses referenced by SysML are available to the user of that model. If the profile is not “strictly” applied, then additional UML metaclasses that were not explicitly referenced may also be available.

— SysML1.2 p. 8

» What does the visibility (private, public, …) means for a block?

As any model elements, the visibility of a block describes how it can be imported outside its namespace.

Note It depends on the tool support for visibility controls to use this feature.

» What is the difference between an internal and a self transition?

In a self transition the exit and the the entry events are trigered.

» Can I attach a History pseudostate to a particular (non composite) state?

No. The History pseudostate (H) is indicated inside a composite state and means that when back in this superstate, the machine goes back to its last active state.

» Divers

Quelques autres questions que je laisse à votre sagacité :

  • Why do systems engineer need yet-another-modeling-language?
  • What is the relationship between “open source SysML” and “OMG SysML”?
  • What is the roadmap for OMG SysML 2.0?
  • Who are the SysML Partners?
  • What is the relationship between UML and SysML? Can SysML and UML be used together?
  • Can SysML be customized?
  • Which language is easier to learn, SysML or UML?

A propos de ce document…

Dernière MAJ : 06/11/2012 - 23:18:17 CET
Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham. La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert. Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

Les références…

  • [FIO2012] Fiorèse S., Meinadier J., Découvrir et comprendre l’ingénierie système, AFIS 2012.

  • [FMS] Friedenthal…

  • [HAS2012] Haskins C., SE Handbook Working Group, INCOSE Systems Engineering Handbook: Version 3.2.2, International Council on Systems Engineering, 2012.

  • [KAP2007] Kapurch S., NASA Systems Engineering Handbook, 2007 (pdf).

  • [REQ2012] Guide Bonnes Pratiques en Ingénierie des Exigences, AFIS 2012.

  • [Roques2010] Pascal Roques. SysML par l’exemple - Un langage de modélisation pour systèmes complexes. Eyrolles. a acheter ici.

  • [SeeBook2012] Kordon et al. To be published. XXX

  • [SysML] OMG. Systems modeling language version 1.3. Technical report, 2012.

  • [taoup] Eric Steven Raymond. The Art of Unix Programming. Addison-Wesley. ISBN 0-13-142901-9.

  • [Walsh1999] Norman Walsh & Leonard Muellner. DocBook - The Definitive Guide. O’Reilly & Associates. 1999. ISBN 1-56592-580-7.

Glossaire

Note
Ressources

Les définitions ci-dessous sont regroupées à titre indicatif. Les sources utilisées sont :
DRY

Don’t Repeat Yourself : Un bon principe qui veut qu’on évite de répéter des tâches manuelles (comme les tests) en utilisant plutôt des scripts et des programmes.

INCOSE

International Council on Systems Engineering : une organisation fondée en 1990 pour faire avancer les technologies d’Ingénierie Système .

IPT

Integrated Product Team : une équipe classique en développement système.

OMG

Object Management Group : L’organisme international chargé des principales normes liés à l’objet (CORBA, UML, etc.).

TDD

Test Driven Development : Développements dirigés par les tests. On écrit les tests avant d'écrire le code. On travaille son code tant que les tests ne passent pas.

TRL

Technology Readiness Level : système de mesure employé par des agences gouvernementales américaines et par de nombreuses compagnies (et agences) mondiales afin d'évaluer le niveau de maturité d’une technologie (cf. Wikipedia).

SysML

System Modeling Language ™ : le langage de modélisation de systèmes maintenu par l’OMG.